Content starts here Brief Overview of Service Data Objects
This page last changed on Mar 11, 2008.

eDocs Home > BEA AquaLogic Data Services Platform Documentation > Data Services Developer's Guide > Contents

Test Update Procedures Using SDO Data Graphs

This topic is a brief overview of Service Data Objects and data graphs, which you use to test update procedures in Studio.

Key Points

  • To test an Update procedure in Test view, you must submit a data graph as an argument.
  • A data graph is an XML structure that contains the data you are changing, as well as the original data.
  • When you update a relational data source, ALDSP uses optimistic locking. The data source is locked at update, not when the data is initially retrieved.

Updates in Test View 

When you test an Update procedure in Test view, you are actually updating a Service Data Object (SDO) from within Studio.

Selecting an Update Procedure in Test View

SDO is a programming model for Java platforms that unifies data programming across many types of data sources. SDO is based on data objects, which are simply object instances that contain data. You can update the data objects using either static or dynamic data APIs. With a static API, the shape of the data is defined in advance. However, with a dynamic data API, you can update properties at run time that are not known at development time.

The SDO model is based on data graphs, which are collections of tree-structured data, usually XML. A client retrieves a data graph from a data source, modifies it, and applies the data graph back to the data source.

A data graph contains a <changeSummary> element with the original data you are updating. It also contains an XML element with the new data. When both the old and new data are passed back to the data object, the object can be updated.

A Data Graph with Old and New Data
<sdo:datagraph xmlns:sdo="commonj.sdo">
  <changeSummary>
    <sim:SIMPLE_CUSTOMER sdo:ref="#/sdo:datagraph/sim:SIMPLE_CUSTOMER" xmlns:sim="ld:logical/SimpleCustomer">
      <CUSTOMER_SINCE>1999-01-01T00:00:00</CUSTOMER_SINCE>
    </sim:SIMPLE_CUSTOMER>
  </changeSummary>
  <sim:SIMPLE_CUSTOMER xmlns:sim="ld:logical/SimpleCustomer">
    <CUSTOMER_ID>CUSTOMER7</CUSTOMER_ID>
    <CUSTOMER_SINCE>2007-11-11T00:00:00</CUSTOMER_SINCE>
  </sim:SIMPLE_CUSTOMER>
</sdo:datagraph>

Optimistic Locking 

When an SDO updates a relational source, it uses optimistic locking to avoid change conflicts. With optimistic locking, the data source is not locked after the client acquires the data. Later, when an update is needed, the data in the source is compared to a copy of the data taken when it was acquired. If any of the underlying data was changed before the client applies the changes, the update is rejected, and the client must recover.

The optimistic locking policy is set for each relational data source.

See Also

How To
Concepts
Other Resources
Document generated by Confluence on Apr 28, 2008 15:57